TCP (Transmission Control Protocol) and similar network protocols provide reliable transmission of data between nodes separated by an unreliable network which may drop, corrupt or reorder in-flight packets. Such protocols typically rely on retransmission of missing data packets to provide reliable delivery. Retransmission has a latency drawback as it is necessary to inform the sender which packets require retransmission, which imposes a round-trip-time delay in packet delivery which may be visible to the application. For interactive services on networks with a high probability of packet loss, these delays impact the usability of the service.
There have been attempts to apply forward error correction (FEC) techniques to overcome packet loss in the network. According to such techniques, the sender transmits a predefined number of data packets, commonly referred to as an FEC epoch, and follows that up with transmission of one or more FEC packets that the receiver can use to repair instances of data packet loss. While helpful in some circumstances, this technique cannot guarantee reliable delivery on its own, e.g., when the number of dropped data packets is greater than the number of FEC packets.
There have been attempts to build protocols with both techniques operating simultaneously, transmitting FEC packets and also applying traditional retransmission to correct any packets that could not be repaired by FEC. However, current solutions to combine the two approaches have added too much complexity or have not led to significant improvements in the transmission latency.